<html>
<body>

<p align="justify">
Provides the core functionality of the Border Gateway Protocol version 4
(BGP-4).  This package also contains subpackages which are necessary for the
protocol's proper implementation.  The reason for subpackaging is primarily for
code modularity and readability.  The subpackages are:
</p>

<ul>
  <li>{@link SSF.OS.BGP4.Comm}
  <li>{@link SSF.OS.BGP4.Path}
  <li>{@link SSF.OS.BGP4.Policy}
  <li>{@link SSF.OS.BGP4.Timing}
  <li>{@link SSF.OS.BGP4.Util}
</ul>

<p align="justify">
Three other supplementary subpackages are included to provide support for model
experimentation: {@link SSF.OS.BGP4.Players}, {@link SSF.OS.BGP4.Widgets}, and
{@link SSF.OS.BGP4.test.App}.
</p>

<p align="justify">
The Border Gateway Protocol is the de facto standard inter-domain routing
protocol in today's global Internet.  Its purpose is to build up forwarding
tables (often incorrectly referred to as "routing tables") to be used by a
router when forwarding data packets around an internetwork.  It does so in a
distributed fashion: all routers running BGP in the entire internetwork share
reachability information with each other.  When faced with multiple routes to
the same destination, a selection is made based on several factors, many of
which can be configured by the administrator.  Most commonly, shortest
autonomous system (AS) path length is the primary factor.
</p>

<p align="justify">
The specifications upon which this implementation is based are given in the
Internet Engineering Task Force's Request for Comments number 1771 (RFC 1771),
"<a href="http://www.ietf.cnri.reston.va.us/rfc/rfc1771.txt">A Border Gateway
Protocol 4</a>".  Following are the details of the implementation, including
explanations where it differs from this specification.
</p>

<p align="justify">
<b>IBGP/EBGP</b> This implementation simulates both Internal BGP and External
BGP.  Route reflection--an extension for IBGP--has also been implemented.  (See
section 9.2.1 of RFC 1771 for a discussion of Internal BGP.)
</p>

<p align="justify">
<b>RIB</b> The Routing Information Base (RIB), which stores route information,
is implemented with a type of binary tree called a radix tree (the
specification leaves the specific implementation of the RIB up to the
implementor).  As described in section 3.2 of RFC 1771, there are three
sections to the RIB, each of which has been implemented in compliance with the
specification.
</p>

<p align="justify">
<b>Messages</b> All message types used by BGP (Open, Update, Notification, and
KeepAlive) contain the same fields as given in the specification, with a few
exceptions.  Fields which specify the length in bytes of a message and any
fields used for authentication have been omitted.  In addition, no attempt is
made to make fields the exact size (in number of bits or bytes) as given in the
specification, as these are irrelevant in the simulation.  Message-related
classes can be found in subpackage {@link SSF.OS.BGP4.Comm}, except for {@link
SSF.OS.BGP4.Timing.TimeoutMessage} which is in subpackage {@link
SSF.OS.BGP4.Timing}.
</p>

<p align="justify">
<b>Error Handling</b> No error handling (as per section 6 of the specification)
is implemented.  Error handling is typically used for catching syntactical
errors in messages.
</p>

<p align="justify">
<b>Update Message Handling</b> The handling of Update messages (the type which
carry route information) is fully implemented.
</p>

<p align="justify">
<b>Path Attributes</b> All standard path attributes have been implemented,
though some have not been extensively tested.  Attribute-related classes can be
found in subpackage {@link SSF.OS.BGP4.Path}.
</p>

<p align="justify">
<b>Timers</b> All five timers used by BGP are implemented, with time interval
defaults as suggested in Appendix section 6.4 of RFC 1771.  Timing-related
classes can be found in subpackage {@link SSF.OS.BGP4.Timing}.
</p>

<p align="justify">
<b>Jitter</b> RFC 1771 requires that three of the timers be jittered (Minimum
AS Origination, Keep Alive, and Minimum Route Advertisement--see section
9.2.2.3).  Jitter on any or all of them can optionally be switched off.
</p>

<p align="justify">
<b>Finite State Machine</b> The primary behavior of BGP is defined in one
method which handles all BGP messages and events (method {@link
SSF.OS.BGP4.BGPSession#handle_event()}).  It reacts to the incoming
message/event based on its type and the current state of BGP.  From here, some
helper methods may be called to manipulate the RIB and to compose and send
messages, if necessary.
</p>

<p align="justify">
<b>Route Reflection</b> Route reflection, which is a BGP extension, is fully
implemented.
</p>

<p align="justify">
<b>Policy (Route Filtering)</b> This implementation also supports, in addition
to the core required behaviors, a policy configuration (route filtering) scheme
along the lines of those used by well-known vendors and following the
suggestions in <a href="ftp://ftp.isi.edu/in-notes/rfc1772.txt">RFC 1772</a>.
This feature has not yet been exercised as fully as most others, and should be
used with care.  Policy-related classes can be found in subpackage {@link
SSF.OS.BGP4.Policy}.
</p>

<p align="justify">
<b>Route Flap Damping</b> Support for route flap damping, as described in <a
href="ftp://ftp.isi.edu/in-notes/rfc2439.txt">RFC 2439</a> and <a
href="ftp://ftp.ripe.net/ripe/docs/ripe-210.txt">RIPE 210</a>, is included.
</p>

<p align="justify">
<b>Validation</b> All of the required behaviors of BGP have been implemented to
our knowledge, though we are still constantly evaluating and testing it to
attempt to verify its correctness.  To this end, a series of validation tests
have been composed which exercise these required behaviors.
</p>

<p>
<b>Configuration</b> See distribution file
<code>ssfnet/src/SSF/OS/BGP4/doc/index.html</code>.
</p>

@see SSF.OS.BGP4.Comm
@see SSF.OS.BGP4.Path
@see SSF.OS.BGP4.Players
@see SSF.OS.BGP4.Policy
@see SSF.OS.BGP4.Timing
@see SSF.OS.BGP4.Util
@see SSF.OS.BGP4.Widgets
@see SSF.OS.BGP4.test.App

</body>
</html>
